Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@web_interface/blueprints/api_v3.py`:
- Around line 1674-1684: The git subprocess commands (branch, status, log, and
remote) are not checking return codes before using their output. If any command
fails, the empty stdout is silently treated as a clean state (dirty: false,
empty strings). Check the returncode attribute of each subprocess.run() result
and if any command fails (returncode != 0), return an error response with a
clear message explaining which git command failed, rather than proceeding with
empty/blank values that misrepresent the repository state.
- Around line 1591-1599: The subprocess output from pip operations is unbounded
and can consume significant RAM on Raspberry Pi, especially with verbose
dependency resolution or build failures. Create a shared helper function that
captures only the last N bytes or lines of the combined stdout and stderr, and
includes the command, return code, and timeout context in the output. Apply this
helper to limit the output in the jsonify response's output field in both the
pip install operation at lines 1591-1599 (where subprocess.run is called and the
output field is populated in the jsonify response) and the similar pip operation
at lines 1607-1615 (which has an equivalent unbounded output field in its
jsonify response), replacing the direct concatenation of result.stdout and
result.stderr with calls to this new helper function.
- Around line 1600-1602: In the elif block for the 'install_plugin_requirements'
action, change the reference from the module-level plugin_manager to
api_v3.plugin_manager in the ternary expression on line 1601. This ensures
consistency with how plugin managers are accessed throughout the rest of the
blueprint and prevents inadvertently falling back to the PROJECT_ROOT /
'plugin-repos' default when only the blueprint attribute is initialized. Replace
plugin_manager with api_v3.plugin_manager in the condition that determines which
plugins directory to use.
- Around line 1677-1683: The remote_url field in the jsonify return statement is
including the raw output from git remote get-url, which may contain embedded
credentials in HTTPS URLs (e.g., https://user:password@github.com/repo.git).
Before including remote.stdout.strip() as the remote_url value in the response,
parse the URL using a library like urllib.parse to remove any user
authentication information, or extract only the safe components (protocol, host,
path) and reconstruct the URL without credentials. This prevents accidental
credential exposure in the API response.
- Around line 1640-1646: The `clear_pycache` action increments the `cleared`
counter unconditionally even though `shutil.rmtree()` is called with
`ignore_errors=True`, meaning failed deletions are still counted as successful.
Fix this by removing `ignore_errors=True` from the shutil.rmtree call in the
rglob loop and wrapping it in a try-except block. Only increment the `cleared`
counter when deletion succeeds, and track any failures in a separate counter.
Return both the cleared count and failed count (or a descriptive error message)
in the jsonify response so users get accurate feedback about what was actually
deleted versus what failed.
- Around line 1625-1633: The git commands in the subprocess.run calls rely on
PATH lookup without verifying git is available, which is inconsistent with the
existing pattern used for _SUDO and _JOURNALCTL. Add _GIT = shutil.which('git')
near the top of the module alongside the other tool resolution constants, then
validate that _GIT is not None at the start of both execute_system_action() and
get_git_info() functions by returning a jsonify response with status 503 if the
git command is unavailable, and finally replace all instances of 'git' strings
in the subprocess.run() calls within these endpoints with the resolved _GIT
variable path.

In `@web_interface/blueprints/pages_v3.py`:
- Around line 457-459: The exception handler for the Tools partial uses an
overly broad `except Exception` clause and lacks debugging context for remote
Raspberry Pi environments. Replace the broad `except Exception` with specific
template-related exceptions (such as TemplateNotFound, TemplateError, or other
Jinja2/Flask template exceptions) to catch only relevant errors. Update the
logger.error call to include the `[Pages V3][Tools]` context prefix in the log
message to provide structured logging context for troubleshooting. Additionally,
update the returned error message string to also include the `[Pages V3][Tools]`
prefix for consistency in error responses, ensuring both logs and client-facing
messages provide clear context about which component failed.

In `@web_interface/templates/v3/base.html`:
- Around line 1298-1308: The Tools tab in the template relies solely on HTMX
loading via hx-get without any fallback mechanism, whereas other tabs have
fallback paths in the loadTabContent function. Add a non-HTMX fallback branch in
the loadTabContent function to handle the Tools tab (when activeTab === 'tools')
so that if HTMX fails or is disabled, the tab content can still load gracefully
instead of remaining blank. Ensure the fallback mimics how other tabs in
loadTabContent degrade gracefully.

In `@web_interface/templates/v3/partials/tools.html`:
- Around line 222-246: The toolsAction function makes unauthenticated requests
to the /api/v3/system/action endpoint which performs dangerous state-changing
operations. Add authentication to protect this endpoint by modifying the fetch
call in toolsAction to include an authentication token or credential in the
request headers, and update the corresponding backend execute_system_action
endpoint to validate this authentication before allowing any system action to
proceed. This ensures only authorized clients can trigger destructive operations
like git reset, pip install, or service restarts.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@web_interface/blueprints/api_v3.py`:
- Around line 1672-1690: The per-plugin install loop in the plugin requirements
handler is letting subprocess exceptions escape, which collapses the whole batch
into one generic failure. Update the logic around the subprocess.run call in the
plugins_dir loop to catch TimeoutExpired/OSError per plugin, append a failed
result entry with the plugin name and error text, and then continue iterating so
the existing results breakdown stays accurate. Keep the success/error summary
based on the accumulated results from this handler.
- Around line 825-838: The `double_sided_copies` validation in `api_v3.py` only
enforces the numeric range, but it also needs to match the selected hardware
dimension. Update the `ds_config` handling so that after parsing `copies`, it
checks divisibility against `chain_length` when `double_sided_axis` is
`horizontal` and against `parallel` when `double_sided_axis` is `vertical`; if
the value does not divide evenly, return a 400 error with a clear validation
message. Keep the existing `double_sided_axis` and range checks, and apply the
new logic in the same request path where `ds_config['copies']` is set.
- Around line 813-839: The double-sided form fields are being handled in the
display-specific block but still fall through to the generic config merge,
causing stray root-level keys to persist. Update the save flow in api_v3.py so
the double-sided handling in the current_config['display']['double_sided'] block
either removes double_sided_enabled, double_sided_copies, and double_sided_axis
from data after processing or explicitly excludes them from the later merge
loop. Use the existing double_sided_fields logic and the generic merge section
to ensure these keys are only stored under display.double_sided and never at the
config root.

In `@web_interface/templates/v3/partials/tools.html`:
- Around line 19-20: The “Pull latest (rebase)” tooltip in tools.html overstates
the behavior by promising stash restoration that the backend does not perform.
Update the copy for this action to match the actual git_pull flow: it stashes
local changes and runs git pull --rebase, but does not reapply the stash
afterward. Keep the wording aligned with the tool label and the git_pull
behavior so the UI no longer claims “then restores the stash.”
- Around line 266-299: The git info fetch flow in the panel rendering logic is
treating backend error responses as normal data, causing a false “clean” state
instead of showing the real failure. Update the fetch handling around r.json()
in the git-info block to check r.ok or an error status field before building the
badge and HTML. If the response indicates an error, render d.message in the
panel instead of deriving branch/dirty UI from the payload, and keep the
existing .catch path for transport failures.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@web_interface/blueprints/api_v3.py`:
- Around line 1672-1690: The per-plugin install loop in the plugin requirements
handler is letting subprocess exceptions escape, which collapses the whole batch
into one generic failure. Update the logic around the subprocess.run call in the
plugins_dir loop to catch TimeoutExpired/OSError per plugin, append a failed
result entry with the plugin name and error text, and then continue iterating so
the existing results breakdown stays accurate. Keep the success/error summary
based on the accumulated results from this handler.
- Around line 825-838: The `double_sided_copies` validation in `api_v3.py` only
enforces the numeric range, but it also needs to match the selected hardware
dimension. Update the `ds_config` handling so that after parsing `copies`, it
checks divisibility against `chain_length` when `double_sided_axis` is
`horizontal` and against `parallel` when `double_sided_axis` is `vertical`; if
the value does not divide evenly, return a 400 error with a clear validation
message. Keep the existing `double_sided_axis` and range checks, and apply the
new logic in the same request path where `ds_config['copies']` is set.
- Around line 813-839: The double-sided form fields are being handled in the
display-specific block but still fall through to the generic config merge,
causing stray root-level keys to persist. Update the save flow in api_v3.py so
the double-sided handling in the current_config['display']['double_sided'] block
either removes double_sided_enabled, double_sided_copies, and double_sided_axis
from data after processing or explicitly excludes them from the later merge
loop. Use the existing double_sided_fields logic and the generic merge section
to ensure these keys are only stored under display.double_sided and never at the
config root.

In `@web_interface/templates/v3/partials/tools.html`:
- Around line 19-20: The “Pull latest (rebase)” tooltip in tools.html overstates
the behavior by promising stash restoration that the backend does not perform.
Update the copy for this action to match the actual git_pull flow: it stashes
local changes and runs git pull --rebase, but does not reapply the stash
afterward. Keep the wording aligned with the tool label and the git_pull
behavior so the UI no longer claims “then restores the stash.”
- Around line 266-299: The git info fetch flow in the panel rendering logic is
treating backend error responses as normal data, causing a false “clean” state
instead of showing the real failure. Update the fetch handling around r.json()
in the git-info block to check r.ok or an error status field before building the
badge and HTML. If the response indicates an error, render d.message in the
panel instead of deriving branch/dirty UI from the payload, and keep the
existing .catch path for transport failures.